------------------
BAAD ANGARRU! NINNGHIZZHIDDA!
Open the gate, that I may enter.
Open, lest I attack the gate!
Open, lest I break down the walls!
Open the gate, lest I cause the dead to outnumber the living!
Open the gate, lest I cause the dead to rise and devour the living!

posted 09-24-2001 03:27 AM           

Be that as it may, it's still a very relevant and interesting capability that can potentially solve a lot of problems and open doors to creativity.
For example, it can be used to create subtle radiosity effects, soften and smooth-out shadow edges without huge compile times, mitigate problems with overdark/overbright areas, and create pseudo-ambient lighting effects on outdoor surfaces of lightmapped structures in terrainmaps.

However, lighting effects(brightness) added to the map will not have an associated lightsource, so player models standing in an added pool of light, for instance, will not be lit.
You have to be careful that you don't create new problems while fixing others.

The basic concepts of lightmap extraction and editing are relatively straight-forward and simple to learn, but can be difficult to implement in a large complex map, due to the sheer complexity of the lightmap.

A tutorial on this subject would need to mostly consist of a method for identifying areas of the lightmap(screenshots can be helpful while editing), painting lessons(you are essentially painting with light and shadow, like a fine artist would), and an overview of the relevant tools in Photoshop.
Simple smoothing of shadows with the blur and paintbrush tools is pretty easy to master with a little practice.

------------------
Help us standardise map submissions!:
map-mapname-author
map beta 1-mapname-author

posted 09-24-2001 05:35 AM          

Isn't this type of stuff handled with the 3D lighting grid ? If it is, I guess one could go painting in that one too =)

Seriously, I'm not sure about that lightmaps-disappearing thing. Keep in mind that every lightsource will, Doom III style, be another pass. You can pretty much forget about setting up ambient lighting with many small lights this way. And if you try the same with a small number of large lights, you'll get very hard, and very big, shadows, quickly ruining the illusion.
So dynamic lights, the "real" thing, is ok for dark stuff like Doom III, but as long as hardware doesn't do 200 passes like it now does 4, I can see how lightmaps are still useful as the "bottom" light layer just for filler, to avoid having to do everything in a dynamic way...
Correct me if I'm wrong, I don't map =)

posted 09-24-2001 10:00 AM           

Lightmap editing is a very powerful tool, and it seems like it could become a specialty in the foreseeable future, like map polishing and texturing, but it requires some degree of artistic prowess and a working knowledge of how light and shadow interact.
ie: if one can draw well, lightmap editing will be a cinch.
>
The lightgrid is more or less like a 3D version of lightsubdivide; it controls how often world lighting affects entities in the map. It's a global light resolution setting, so to speak.
The courser the grid, the lower the memory needed, but the greater the chance that an entity will not be in a zone that can recieve lighting.
It's entirely possible for lightgrid values that work perfectly in one map, to result in darkened entities in another.
Lightmaps are not related to it at all.
If a surface has a lightmap, it should also have a corresponding light entititty.

BTW, I have often wished for a lightgrid indicator in the orthographic windows in Radiant, similar to the "blocks" feature, and I suspect would be just as easy to implement. That way we could optimize the structures to fit the lightgrid.
>
With regard to cutting-edge mapping, I see lightmaps completely disappearing within a few years though, since they require compiling, and are essentially just painted-on illusions of light, and use up one pass by themselves anyway.
ie: lightmaps are not actually "free", although most modern videocards can expend at least one pass without dropping frames.
Even now, we possess videocards that are capable of realtime lighting and transformation, but those capabilities are being vastly under-utilized.

posted 09-24-2001 11:44 AM          

quote:

---

Originally posted by snickelfritz: With regard to cutting-edge mapping, I see lightmaps completely disappearing within a few years though, since they require compiling, and are essentially just painted-on illusions of light, and use up one pass by themselves anyway.

---

That's true, but they use one pass independent of the number of lights. Current realtime lighting technologies (e.g. Doom3's) tend to use one pass per light. You can have a hundred lights in a Quake3 scene for zero runtime cost relative to one light. Try a hundred lights in Doom and you'll be getting 0.1fps. Put another way, lightmaps are generally O(1) and realtime lighting O(n), where n is the number of lights.

Lightmaps are also more flexible in many ways. Since they don't have to go through the limited functionality of the GPU you can do any preprocessing you want - radiosity, caustics, filtering, etc.

The disadvantage is that lightmaps are hard to integrate with bumpmapping, something that current realtime systems using dot3 lighting do very well.

I think lightmaps (or at least some precalculated lighting function) will be around for a long time to come. Current realtime lighting techniques just aren't flexible or general enough to replace them.

quote:

---

Even now, we possess videocards that are capable of realtime lighting and transformation, but those capabilities are being vastly under-utilized.

---

Doom3 will push it to the limit, and you're looking at 3 lights per scene at reasonable fps, and ugly hard shadows. Quake3 quality lighting in real time will not be possible for another six years or so (EDIT: On second thoughts, make that ten years). Quake2 quality (i.e. radiosity) will be even longer than that, probably twenty.

quote:

---

The emminent release of the X-Box is also a major contributor to this hypothesis; if console games look better than PC games...well, you know the rest.

---

Er.. not quite sure what you mean there.

posted 09-24-2001 02:54 PM           

BTW, I still have a few computer graphics magazines from 1997 with articles about game design and mapping that specifically state that 24bit images will probably never be practical in realtime gaming due to the huge rendering overhead.(the articles featured 24bit development screens that would not actually be used in games)

That was about one year before the introduction of the TNT chipset, which turned out to be an excellent 32bit accelerator. If you follow the lineage of that technology, current accelerators only 4 years later are in the neighborhood of 5-10x the speed, and with a far greater range of rastor operations.
No one predicted it, and 3dfx vehemently opposed the idea as being totally impractical at the time.

posted 09-25-2001 03:08 AM          

I think I was wrong on one point though - lightmaps themselves will be useless in five years or so. By then the poly density will make good vertex lighting indistinguishable. But I still think pre-calculated lighting will be around for a good while yet.

posted 09-25-2001 07:29 AM          

Snick, I appreciate your continuing q3ase support as always -- and its not like I feel 'attacked' somehow when you diss the lightmap
It's just that I've spent some time in global illumination, and there is a lot that is involved there that cannot be done realtime -- and wont be for a long time.
What I meant was that this doesn't matter in environments, such as Doom III, where all you want is a hard, sharp spot in otherwise almost unlit areas -- but as you want to do something more 'normal', global illumination is a huge factor. And this GI business is exactly what lightmaps, in a very rudimentary way, have been trying to fake; and it is also what realtime lights have a very difficult time to fake.

So for urban settings and the likes, I can see how lightmaps still have some life in them. They just won't be the same lightmaps that we have now. Aside from the obvious improvements such as increased sampling density, you must also remember that graphics gurus have a lot of tricks up their sleeve that have so far been completely unexploited in games.

One example is shadow subdivision, where the geometry is cut up in a different way to follow the lines of a shadow; a lightmap applied to such a geometry will have a hard shadow, rather than the blurry, blocky staircasing jaggies we've come to expect from lightmaps.
So that's just one thing -- and the GI people are working on many other tricks to fix the other shortcomings of 'the lightmap'/'radiosity' (specularity, dynamic lighting, transparency...)
The core problem with getting rid of the lightmap is that the realtime lighting support of the current cards is so called "direct lighting" only : they can tell whether a point on a surface can 'see' a light, or not, and consequently render that point lit, or in shadow. That's it. No secondary reflection, no diffuse effects (such as lighbleeding), no specular reflection, no caustics, no refraction...etc.

quote:

---

The basic concepts of lightmap extraction and editing are relatively straight-forward and simple to learn, but can be difficult to implement in a large complex map, due to the sheer complexity of the lightmap. A tutorial on this subject would need to mostly consist of a method for identifying areas of the lightmap(screenshots can be helpful while editing), painting lessons(you are essentially painting with light and shadow, like a fine artist would), and an overview of the relevant tools in Photoshop. Simple smoothing of shadows with the blur and paintbrush tools is pretty easy to master with a little practice. [/B]

---

I hear you on that !

I've been experimenting with a single room containing a column - my initial idea was that thier may be a possibility to create 'decals' on walls and floors, but the limitations due to the low resolution are too great. A single pixel dot will 'blur' outward by about 16 pixels.

I've been trying to figure out how the areas on a lightmap may correllate to the map by either using coloured blocks in the lightmap, or a grid with numbers.

This was going well - until I loaded up a complex map and ended up with 16 TGA files to wade through !

About the only quick and dirty useful thing I can consider right now, is to use a subtle blur filter on all the lightmaps to smooth everything out, or other simple filters, such as contrast and color balance.

Trying to individually fix lighting on a medium to large size map could take just as long as tweaking the lighting in radiant and compiling !

What would be ideal, is an extension to berts q3ase whereby a simple pixel editing toolbox could be used on a loaded up lightmap which would then update the .bsp preview 'realtime'.

Identifying areas of a lightmap otherwise, would require some basic symbol or colour coding - if you have 16 lightmaps, you would use 16 symbols or color blocks on the lightmaps, load them into the .bsp file, fire up quake3 and start making notes

Quite a daunting task...

posted 09-26-2001 10:56 AM          

quote:

---

Originally posted by bushboy: A single pixel dot will 'blur' outward by about 16 pixels.

---

You can fiddle with the -light options to change the lightmap resolution.

posted 09-26-2001 11:14 AM           

quote:

---

Originally posted by Maj: posted 09-24-2001 11:44 AM That's true, but they use one pass independent of the number of lights. Current realtime lighting technologies (e.g. Doom3's) tend to use one pass per light. You can have a hundred lights in a Quake3 scene for zero runtime cost relative to one light. Try a hundred lights in Doom and you'll be getting 0.1fps. Put another way, lightmaps are generally O(1) and realtime lighting O(n), where n is the number of lights.

---

That's not entirely true. According to John Carmack (in an interview held at QuakeCon 2001) each light in Doom will require one (or several) passes per pixel. If you add two or more lights the number of rendering passes increases, just as you said. BUT, this only applies to lights overlapping each other. You can have a good number of lights in a scene, as long as they don't overlap. One ambient light plus a number of spotlights to fill in the scene is still possible. The only big drawback for mappers will be that setting up your lights will be a lot more difficult, since you really have to plan your lighting to have acceptable performance in your map. This could make the new Doom lighting inflexible (or perhaps 'more complex' would be a better description) when compared to current lightmap techniques but I think the added realism will greatly compensate this.

[This message has been edited by r3tina : 09-26-2001.]

quote:

---

Originally posted by Johnny Law: You can fiddle with the -light options to change the lightmap resolution. This increases compile time and texture memory use, of course, so you'd probably only want to do that on a small-ish map.

---

I'd like to experiment with that.
I'm using q3ase to save and load the lightmaps - at present, I'm not sure whether it's q3ase that prevents anything but a 128x128 lightmap being loaded, or whether q3ase is reading the .bsp info to check the size of the lightmap ?

posted 09-26-2001 11:49 AM           

quote:

---

You can fiddle with the -light options to change the lightmap resolution.

---

I'm not convinced that this is actually the case.
The lightmap would not be enlarged with those settings, but rather, the quality of the sampling would be increased, not unlike the difference between various methods of interpolation used in Photoshop when scaling an image.

If it were in fact possible to enlarge the lightmap(raise the resolution), then the method used to create the lightmap would have some measurable effect on in-game performance.
ie: larger, higher-rez lightmaps would consume a greater amount of video memory.
Light, and light -extra both consume the same amount of resources in-game, although light -extra is "higher resolution" in some way.

JL, I guess you were refering to the -samplesize switch in the light section of q3map ?

I tried modifying it to 8, 32 & 64 (it defaults to 16), using the following -samplesize x - I got a number of strange errors in vlight, light -extra doesn't output errors, but it seems to make no difference to the lightmap that q3ase extracted, or any diffence ingame ?

One very useful switch I experimented with though, was 'border' :-

-light -extra -border

It outputs with all the individual lightmaps exactly cordoned of with red lines :-

Loading it into the .bsp :-

Now that is useful stuff indeed !

posted 09-26-2001 12:07 PM          

Hrm, I guess you could use the PVS and cull leaves outside the light's radius, but you certainly couldn't do it accurately. You still have the stencil render and clear per-light as well, so two non-overlapping lights would be quite a bit slower than one big light.

The only big drawback for mappers will be that setting up your lights will be a lot more difficult, since you really have to plan your lighting to have acceptable performance in your map.

Geometry will also have a big impact in non-obvious ways. Imagine a light shining through a number of metal railings, viewed side on. Each railing will add 2 to the depth complexity of the stencil render for that light (although the cost will be reduced cos the depth-test will reject them), so a large number of railings could well kill your framerate with just a single light. The z-reject is blindingly fast on GF3, so this might not be a big problem, but it shows that good performance is not just a case of minimising lights.

Taking my last post one step further :-

=

This is definately a major helper in identifying an exact area in a map that corresponds to the lightmap TGA files !

posted 09-27-2001 03:20 AM          

It's true that extra lights only incur an extra fillrate hit if they happen to shade the same surface pixel, but you still need to transform and clip all relevant geometry into "light space", doing shadow plane extraction etc; which costs CPU & GPU (although this would be cached if the light and geometry don't move).

posted 09-27-2001 03:32 AM           

quote:

---

Originally posted by Maj: *snip* [This message has been edited by Maj : 09-26-2001.]

---

I don't know Maj, I only repeated what I understood from John Carmacks explanation. I think you should be able to find the interviews on Gamespot somewhere, if you haven't seen them already. It's very interesting stuff.

posted 09-27-2001 09:20 AM          

Edit: this all 'by the book'. Maybe the JC-meister has a secret trick

posted 09-27-2001 09:53 AM           

quote:

---

Edit: this all 'by the book'. Maybe the JC-meister has a secret trick [This message has been edited by Bert Peers : 09-27-2001.][/B]

---

Heh heh, he is a coding God after all...

posted 09-27-2001 11:00 AM          

The problem with this approach is that it bumps up the poly counts considerably, since a complex object casting a shadow onto a single tri will cut that tri up a lot. You also run into depth buffer problems, because the depth values for a non-chopped tri are different to the same tri after chopping. That's not a biggie though, some biasing should take care of it in almost all cases.

(Side note: I was idling thinking of writing a q3 light compiler that uses this approach instead of lightmaps. Cute but useless :])

posted 09-28-2001 02:39 AM          

~(Side note: I was idling thinking of writing a q3 light compiler that uses this approach instead of lightmaps. Cute but useless :])~

posted 09-28-2001 03:49 AM          

I was under the impression that although doom3 won't need compiling, that during the process of loading the map, the engine would calculate all the static lights on and through static geometry in advance, and generate a pseudo-lightmap, which would stay in memory. These "pseudo-lightmaps" can then be modifed later as necessary (affected by moving lights, character shadows, etc.). This would mean you could have 100s of static lights in a single scene, even overlapping each other, with no slowdown at all.
Course, I'm not programming the thing (and neither are any of you, so maybe we should shut up about it and let Carmack code =].